FLUTE version 2 (RFC 6726) signalling, off by default: step one of three, no conformance claimed - #65
Conversation
6237b31 to
b5be461
Compare
b5be461 to
26dacc2
Compare
798ddf8 to
1e97d70
Compare
1e97d70 to
5a9496c
Compare
637cf46 to
12fb037
Compare
e033e91 to
0d009e8
Compare
c7306fc to
e6bbe48
Compare
6e90d9f to
22baee6
Compare
4c3e556 to
e6bbe48
Compare
8896a63 to
51b4053
Compare
45f4df6 to
e90c13d
Compare
0395428 to
12119e1
Compare
…ault Change type New feature, not for 3GPP MBMS use. This branch is the FLUTE version 2 delta and nothing else. Basis The two versions are separate protocols, not a compatible upgrade. RFC 3926 clause 3.4.1: "This document specifies FLUTE version 1. Hence in any ALC packet that carries FDT Instance and that belongs to the file delivery session as specified in this specification MUST set this field to '1'." RFC 6726 clause 11.1: "Therefore, an implementation that relies on [RFC3926] and RFC 3451 will not be backwards compatible with FLUTE as specified in this document." RFC 6726 clause 3.1, which is why the receive side checks against a configured value rather than accepting whatever arrives: "If multiple FLUTE sessions are sent to a channel, then receivers MUST determine the FLUTE protocol version, based on version fields and the (source IP address, TSI) pair carried in the ALC/LCT header of the packet." On the LCT generation, RFC 6726 clause 11.1: "In [RFC5651], these fields MUST be set to zero and MUST be ignored by receivers (instead, the EXT_TIME Header Extensions can convey this information if needed)." On the identifier sequence, RFC 6726 clause 3.4.1: "After reaching the maximum value (2^20-1), the numbering starts from the smallest FDT Instance ID value assigned to an expired FDT Instance." and "Senders MUST NOT reuse an FDT Instance ID value that is already in use for a non-expired FDT Instance." On expiry, RFC 6726 clause 3.3: "both a sender and a receiver easily determine to which (136-year) epoch the FDT Instance expiration time value pertains by choosing the epoch for which the expiration time is closest in time to the current time." On a shared Content-Location, RFC 6726 clause 3.4.2: "the element appearing in the FDT Instance with the greater FDT Instance ID is considered to declare a newer instance (e.g., version) of the same" On security, RFC 6726 clause 7.5 takes its service set from ALC, where RFC 5775 requires anti-replay support alongside authentication and integrity. Change A per-session FLUTE version, settable on the Transmitter and Receiver, defaulting to 1, carried into the ALC parser, the FDT and the receiver's object handling. Every behavioural difference below is reached only when a caller selects version 2, so a version 1 or 3GPP session is unchanged in every respect. Signalling: transmit writes the selected version into the EXT_FDT nibble, receive accepts only the configured version, and the RFC 6726 FDT namespace is enabled. LCT generation: under version 2 the two bits RFC 3451 used for the Sender Current Time and Expected Residual Time fields contribute no header words and nothing is stepped over, so an extension placed after the TOI is reached. Under version 1 the RFC 3451 reading is untouched. Transmit has always sent both bits zero, since the header buffer is calloc'd. FDT Instance ID: version 2 wraps to the smallest expired identifier, refuses one still live, and reports exhaustion, which RFC 6726 clause 3.4.1 leaves to the implementation. Version 1 keeps RFC 3926's wrap to zero. Expiry: read into the era nearest the current time, version 2 only. Shared Content-Location: the receiver records which instance declared each file and keeps the one from the greater instance ID rather than whichever completed first, version 2 only. IpSec sets a replay window. That one is version-independent and benefits both. Four further obligations were checked against the specifications and found already met, so no code changed for them: EXT_TIME and EXT_AUTH recognition, the RFC 3450 to RFC 5775 move, the FDT schema body, and ESP authentication and integrity. README-FLUTE-V2.md records each, how it was established, and where the reading is weaker than a test. The default is what keeps this safe: 1 is the version TS 26.346 clause L.4.1 references, so a session that does not ask for version 2 behaves exactly as it does on the version 1 branch. Separation, deliberate Rebuilt on the FLUTE version 1 compliance branch rather than on the FEC branches, so it carries no Raptor and no RaptorQ: zero files of either. The Raptor and RaptorQ test suites are deliberately not registered in tests/CMakeLists.txt here, and the reason is stated at that line. Verification T1: 62 cases pass at the build root, 12 of them in the FluteV2 suite, covering both readings of the LCT bits, the three branches of the version 2 identifier sequence, and the worked example RFC 6726 clause 3.3 gives for the era calculation. Quotations checked with tools/verify-citations.py in --strict mode. T2: ip xfrm state show on an installed association reports "replay-window 32" beside the enc and auth-trunc lines. 32 is the ceiling the legacy attribute expresses, the kernel holding its replay bitmap in a __u32; a request for 64 is clamped. Not in this change Congestion control, which RFC 5775 requires for every packet in a session and which this library does not implement. It is a building block, not a patch, and until it exists no RFC 6726 conformance is claimed for this branch and none can be. It is the only remaining item.
12119e1 to
82e1433
Compare
This pull request: merge it any time after #62Status: ready. One commit, 12 files, +625/-45. 81 cases pass. Independent of the FEC pair, so it can go before or after them. What to do
A correction to an earlier version of this pull request's description. It said of RFC 5775 and RFC 5651 that "neither of the newer documents is held by us, so no version 2 conformance can be asserted either way". That was wrong, and it is what kept #81's second step from being attempted for two weeks. Both documents were available. They have now been read against the code, and the finding is on #81: the LCT header does not change between RFC 3451 and RFC 5651 for any field this library uses, so the second step needed four fixes rather than a re-encoding. Three landed on #62, one on #98, none here. What still blocks a version 2 conformance claim is step three, congestion control, in #98 and untested against a second implementation. How this set of pull requests came to look like this
Where the nine closed pull requests went
One correction, @rjb1000. #93 is listed above as "already merged in PR #60". #60 merged the FDT growth fix on 17 August and changed no test file; Every open issue, and which pull request closes it
Four open issues are deliberately closed by nothing:
The stack, and the order to merge it inGitHub retargets each child to One trap for whoever merges. The heads live in two repositories: #61, #68 and #98 in |
Advances #81. Does not close it, and must not be set to.
Dependencies and issues
Depends on: #62, and is based on its branch, so #62 merges first.
Paired with: #61, #64, #68 and #98, independent of this one, either order.
Closes on merge: nothing. It advances #81 by one of the three steps that issue lists, and #81 must
stay open afterwards.
What is in this pull request
One commit. A per-session FLUTE version, defaulting to 1, plus every version 2 rule that differs
from version 1 except congestion control. Nothing here is reachable from a version 1 or 3GPP
session; each difference is behind the selector.
ExpiresChecked and already met, so no code changed: EXT_TIME and EXT_AUTH recognition (RFC 5651 asks
only that they be recognised, not parsed); the RFC 3450 to RFC 5775 move, whose two substantive
items were already present; the FDT schema body, whose attribute set matches and whose 3GPP extras
the schema itself admits; and ESP authentication and integrity.
README-FLUTE-V2.mdrecords eachof these, how it was established, and where the evidence is a reading rather than a test.
Not implemented: congestion control. RFC 5775 requires it for every packet in a session. It is
a building block, not a patch. No RFC 6726 conformance is claimed for this branch and none can be
until that exists. It is the only remaining item.
What this is not
This is not FLUTE version 2 support, and makes no conformance claim. #81 separates that into three
steps and this is the first. What this earns is that the version stops being hardcoded.
Correction to an earlier version of this description. It said of RFC 5775 and RFC 5651 that "neither
of the newer documents is held by us, so no version 2 conformance can be asserted either way". That was
wrong, and it kept #81's second step from being attempted: both documents are available and have now been
read against this code. The finding is recorded on #81. In short, the LCT header does not change between
RFC 3451 and RFC 5651 for any field this library uses, and RFC 5775 adds two things to RFC 3450 that are
both already present, so the second step needed four fixes rather than a re-encoding. Three of them landed
on #62 and one on #98, none on this branch; this branch stays a single commit.
What still blocks a version 2 conformance claim is the third step: congestion control, implemented in #98
and untested against a second implementation.
Version 1 stays the default because the profile this library's consumers operate, TS 26.517 clause 6.2.1
pointing at TS 26.346 annex L, is scoped to RFC 3926 throughout. That was @davidjwbbc's point on #62, and
it is why this material was split out of that branch rather than merged into it.
Verification
T1: 77 cases passing, including that a version 2 session signals 2 and a version 1 session is unchanged.
No live verification: there is no version 2 peer to test against, and none is claimed.
Merge order
After #62. Independent of the FEC branches.